Info-Mac 4/Info_Mac IV CD-ROM (Pacific HiTech Inc.)(August 1994).iso/Periodicals/CSMP/C.S.M.P. Digest, Issue 3.031

Internet Message Format | 1994-06-09 | 55KB

From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-031
Date: Fri, 27 May 94 14:27:48 MET DST

C.S.M.P. Digest             Fri, 27 May 94       Volume 3 : Issue 31

Today's Topics:

        Any good Mac C books?
        Basic, basic windows & PICT drawing
        Help: Palette translation in CopyBits
        How do I draw masked icons w-System 6?
        Motorola announces Power Mac compilers
        Polling the Serial Port



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                        Sends you a summary of commands
    subscribe csmp-digest Your Name    Adds you to the mailing list
    signoff csmp-digest            Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail]. Currently no previous volumes of the CSMP
digest are available there.

Also, the digests are available to WAIS users as comp.sys.mac.programmer.src.


-------------------------------------------------------

>From [e-mail] (Peter R Alcasid)
Subject: Any good Mac C books?
Date: Fri, 29 Apr 1994 16:37:47 GMT
Organization: Purdue University School of Engineering & Technology at Indianapolis,IN

I'm intrested in programming the Mac using Think C.  Does anyone know of any
good books that gives a step by step tutorial on how to program the Macintosh
(i.e. accessing the Toolbox using C).  I've got Inside Macintosh: Macintosh
Toolbox Essentials but everything is in PASCAL!  Any suggestions would be
appretiated.

Ron Alcasid

+++++++++++++++++++++++++++

>From [e-mail] (Jon Bell)
Date: Sat, 30 Apr 1994 11:05:08 GMT
Organization: Presbyterian College, Clinton, South Carolina USA

In article <[e-mail]>,
Peter R Alcasid <[e-mail]> wrote:
>I'm intrested in programming the Mac using Think C.  Does anyone know of any
>good books that gives a step by step tutorial on how to program the Macintosh
>(i.e. accessing the Toolbox using C).

"Macintosh C Programming Primer", by Dave Mark and Cartwright Reed,
published by Addison-Wesley.  It's in two volumes.

--
Jon Bell <[e-mail]>                        Presbyterian College
Dept. of Physics and Computer Science        Clinton, South Carolina USA

+++++++++++++++++++++++++++

>From [e-mail] (Bob "Skippy" Blechinger)
Date: Wed, 4 May 1994 10:31:01 GMT
Organization: University of South Dakota

[e-mail] (Peter R Alcasid) writes:

>I'm intrested in programming the Mac using Think C.  Does anyone know of any
>good books that gives a step by step tutorial on how to program the Macintosh
>(i.e. accessing the Toolbox using C).  I've got Inside Macintosh: Macintosh
>Toolbox Essentials but everything is in PASCAL!  Any suggestions would be
>appretiated.

>Ron Alcasid

Ron,
  Try "Learn C on the Macintosh" by Dave Mark; it comes with a "lite"
version of Think C, *and* it comes with an upgrade offer to the *full*
Think C for only $129 (this might have changed since I got mine, though)

  After that, you can step up to the "Macintosh C Programming Primer", by
Dave Mark & Cartwright Reed; it's a 2-volume set, and again, quite good...

  Hope this helps!

  -Bob Blechinger
    AppleCore of Siouxland
      Mac Software Director
        Sioux Falls, South Dakota
          [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Dean R Money)
Date: 4 May 1994 16:31:48 GMT
Organization: The Ohio State University

Bob "Skippy" Blechinger <[e-mail]> wrote:
>[e-mail] (Peter R Alcasid) writes:
>>I'm intrested in programming the Mac using Think C.  Does anyone know of any
>>good books that gives a step by step tutorial on how to program the Macintosh
>>(i.e. accessing the Toolbox using C).  I've got Inside Macintosh: Macintosh
>>Toolbox Essentials but everything is in PASCAL!  Any suggestions would be
>>appretiated.
>
>  Try "Learn C on the Macintosh" by Dave Mark; it comes with a "lite"
>version of Think C, *and* it comes with an upgrade offer to the *full*
>Think C for only $129 (this might have changed since I got mine, though)
>
>  After that, you can step up to the "Macintosh C Programming Primer", by
>Dave Mark & Cartwright Reed; it's a 2-volume set, and again, quite good...

I would agree.  Those three books, along with Inside Mac I, II, V, and VI,
not only got me started in programming on the Mac, but helped me learn
C from scratch.  I did know Pascal before, though, so it wasn't difficult
for me to understand the Pascal examples in IM, and make Toolbox calls
in C.

Dean.

+++++++++++++++++++++++++++

>From [e-mail] (SusanLesch)
Date: 4 May 1994 23:33:05 -0400
Organization: America Online, Inc. (1-800-827-6364)

  In article <rfblec.768047461@sunfish>,
  [e-mail] (Bob "Skippy" Blechinger) writes:

> Try "Learn C on the Macintosh" by Dave Mark; it comes
> with a "lite" > version of Think C...

  Oh, dear, no.

  I would _not_ recommend "Learn C on the Macintosh" to
  anyone seriously interested in learning the C language.
  There is no formal definition of all data types, little
  rigor, and a casual attitude that does not lend itself to
  the difficulties of IM. I wish I could suggest an
  alternative, but I must leave that to others.

  For examples, that are, sadly, fairly representative of
  the book on the whole: "long" is never defined, mentioned
  once. "continue" is not in the book. There is an
  incomplete definition of the "if" statement, both in the
  text and the appendix, leaving out the essential form "if
  else"!

  I believe LCOM causes more harm than good.


+++++++++++++++++++++++++++

>From [e-mail] (SusanLesch)
Date: 5 May 1994 00:28:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

  Sorry, I believe in an earlier post I said "if else" is
  not in "Learn C on the Macintosh". It is "else if" that's
  missing. (We're having AOL problems and I can't retrieve
  what I said.)

  While I have the book out, the cover blurb says, among
  other things, "reference material, including glossary,
  Standard Library functions, and a C syntax reference." If
  that's C's syntax, we're all in trouble. For shame,
  Addison-Wesley.

+++++++++++++++++++++++++++

>From [e-mail] (Olli Vuolteenaho)
Date: Fri, 6 May 1994 15:55:15 GMT
Organization: University of Oulu, Department of Physiology

SusanLesch ([e-mail]) wrote:
:   Sorry, I believe in an earlier post I said "if else" is
:   not in "Learn C on the Macintosh". It is "else if" that's
:   missing. (We're having AOL problems and I can't retrieve
:   what I said.)
:
:   While I have the book out, the cover blurb says, among
:   other things, "reference material, including glossary,
:   Standard Library functions, and a C syntax reference." If
:   that's C's syntax, we're all in trouble. For shame,
:   Addison-Wesley.

Sorry for my ignorance, but what kind of special definition
would "else-if" need? It isn't specifically defined, for example,
in Turbo C/C++ reference manual either, is it.

I don't have as pessimistic opinion about Learn C on the Macintosh
as you do.
If you have programming experience it feels awfully slow-paced, but
then it wasn't written for you. I think that it presents the basics
of C in an entertaining way, it might even encourage someone to explore
programming deeper, unlike, for example, Lippman's C++ primer that I've
often seen recommended as the first book on (C++) programming (it's
an excellent book for the more experienced, though).
And BTW, 'long' is explained on p. 207 of my LCOM.

Olli

+++++++++++++++++++++++++++

>From [e-mail] (SusanLesch)
Date: 7 May 1994 00:48:07 -0400
Organization: America Online, Inc. (1-800-827-6364)

  In article <[e-mail]>,
  [e-mail] (Olli Vuolteenaho) writes:

> what kind of special definition would "else-if" need?...

  For a comparison, take the Waite Group's New C Primer
  Plus. There are three forms described for the if
  statement: if, if-else, and if-else if-else. Lacking
  else-if, a newbie (like me :-) might wind up with nested
  if's, sort of like wasting time with case statements.

> [Learn C on the Macintosh] presents the basics of C in an
> entertaining way, it might even encourage someone to
> explore programming deeper

  Sure, entertainment is part of education. But if
  substance is forfeited in exchange, I am worried. Perhaps
  if the book were titled "Learn C Basics on the
  Macintosh", I wouldn't object so much. It's the reader
  being led to think this is comprehensive C that offends
  me. I'd also like to be taught good habits and structure.

  On another tack, take the first incarnation of HyperCard,
  which was presented in an equally "entertaining way" and
  could "encourage" someone to "explore programming
  deeper". The problem here is similar. An informal
  definition of a language, perhaps encouraging
  lackadaisical programming practices, without mention of
  error-checking is _lots_ of fun!

> And BTW, 'long' is explained on p. 207 of my LCOM.

  Yes, in passing, in the middle of an exercise on dice
  rolling, in a chapter titled "Variable Data Types" that
  doesn't define them. Where is the formal presentation of
  data types? Again using New C Primer Plus as a
  comparison, long, int, char, unsigned, float, and double
  are neatly presented in one chapter (3).

  Thank you for responding, by the way. Mr. Mark's books
  are extremely popular, and I would not expect many people
  to agree with my assessment of Learn C on the Macintosh.

+++++++++++++++++++++++++++

>From [e-mail] ( nick.c )
Date: 7 May 94 20:55:24 GMT
Organization: (none)

In Article <2q9pdh$[e-mail]>, [e-mail]
(SusanLesch) wrote:

>  I would _not_ recommend "Learn C on the Macintosh" to
>  anyone seriously interested in learning the C language.
>  There is no formal definition of all data types, little
>  rigor, and a casual attitude that does not lend itself to
>  the difficulties of IM.

    While I disagree with this assessment of _Learn_C_on_the
  Macintosh_ (I'm reading the C++ version now, and find it quite
  informative, as I found the C one), if you want rigor and
  less casual an aproach (and even if you don't) you should have
  a copy of Kernigan and Ritchie.  This is probably stating the
  obvious, but since it is the *definitive* work, you should have
  a copy - no matter what you're doing with C.



   _/   _/  _/  _/_/_/   _/   _/  Sea Shells to C shells,  Waikiki to
  _/_/ _/  _/  _/   _/  _/_/_/     the Internet, a wave, is a wave...
 _/ _/_/  _/  _/       _/ _/
_/   _/  _/   _/_/_/  _/   _/  CompSrv: 71232,766 I-Net: [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] ([e-mail])
Date: 9 May 1994 04:07:27 -0000
Organization: Delphi Internet Services Corporation

[e-mail] ( nick.c ) writes:

>In Article <2q9pdh$[e-mail]>, [e-mail]
>(SusanLesch) wrote:

>>  I would _not_ recommend "Learn C on the Macintosh" to
>>  anyone seriously interested in learning the C language.
>>  There is no formal definition of all data types, little
>>  rigor, and a casual attitude that does not lend itself to
>>  the difficulties of IM.

>    While I disagree with this assessment of _Learn_C_on_the
>  Macintosh_ (I'm reading the C++ version now, and find it quite
>  informative, as I found the C one), if you want rigor and
>  less casual an aproach (and even if you don't) you should have
>  a copy of Kernigan and Ritchie.  This is probably stating the
>  obvious, but since it is the *definitive* work, you should have
>  a copy - no matter what you're doing with C.

If you're learning C++ from Learn C++ on the Macintosh, you're going
to have serious problems using C++ for any medium to large-sized
project.  I agree with Susan on "Learn C.."- I know of no one who has
actually learned good C programming from it.  There are *good* C (and
C++) books out there.  They usually assume you have a PC or Unix, but
so does "Learn C on the Macintosh" (printf and fopen are not Macintosh
calls, you see).  Get one of them instead.

You might find the C++ book "quite informative," but that doesn't
change the fact that it does not teach correct use of C++.  Among
other things, it does not mention virtual destructors once.  It says
that because constructors *never* return anything, one should not
allocate memory in them, and discusses a "two-stage" workaround for
this "problem." It does not teach proper inheritence theory.  A review
I read of the book in DDJ mentioned that the book would only be useful
as a doorstop.  I happen to agree.

Chris

+++++++++++++++++++++++++++

>From $[e-mail] (Stephan Fassmann)
Date: 9 May 1994 18:39:34 GMT
Organization: Brigham Young University

In article <2qkctv$[e-mail]> [e-mail] ([e-mail]) writes:
>If you're learning C++ from Learn C++ on the Macintosh, you're going
>to have serious problems using C++ for any medium to large-sized
>project.  I agree with Susan on "Learn C.."- I know of no one who has
>actually learned good C programming from it.  There are *good* C (and
>C++) books out there.  They usually assume you have a PC or Unix, but
>so does "Learn C on the Macintosh" (printf and fopen are not Macintosh
>calls, you see).  Get one of them instead.

    How about a nice list, Because I would like to get some books on Mac
c/C++ programing.

Stephan Fassmann   InterNet: $[e-mail]   GEnie: S.FASSMANN
carpe diem                                                carpe noctem

+++++++++++++++++++++++++++

>From [e-mail]
Date: Tue, 10 May 1994 02:41:47 EST
Organization: BMUG Boston

>> I believe ["Learn C on the Macintosh" by Dave Mark] causes more harm than
good.<<

Can you offer an alternative text to use, then? I'm also beginning to learn C
and LCOM doesn't feel like a "serious" enough book to begin learning C from. I
also have the Waite group's New C Primer Plus. Is that any better? (As you can
see, since I'm just beginning, I'm more interested in learning C itself rather
than how it applies directly to the Mac yet.)
-BMUG Boston 617-721-5840, East Coast BBS of The World's Largest Mac User Group

+++++++++++++++++++++++++++

>From [e-mail] (SusanLesch)
Date: 10 May 1994 17:21:04 -0400
Organization: America Online, Inc. (1-800-827-6364)

  In article
  <[e-mail]>,
  [e-mail] writes:

  >> I believe ["Learn C on the Macintosh" by Dave Mark]
  causes more harm than good.<< (-SGL)

> I also have the Waite group's New C Primer Plus. Is that
> any better? (-JC)

  Well, I am no expert, and am as interested in seeing the
  names of some good books as anyone. I used "New C Primer
  Plus" and loved it. The comparisons between K&R and ANSI
  C are simply great. As the only caveat, I skimmed the PC
  / Unix / DOS sections on command lines for the most part,
  keeping in mind that the authors tried to be somewhat
  Macintosh and THINK C aware. My vote says yes, by all
  means, use it.

  "New C Primer Plus" is being used on America Online to
  teach C right now in a cross-platform class in their
  online Programmer U, if I'm not mistaken.


+++++++++++++++++++++++++++

>From Chris Hanson <[e-mail]>
Date: Wed, 11 May 94 06:50:50 -0600
Organization: Green Dragon Creations, Inc.


In article <$[e-mail]>, Stephan Fassmann writes:

>
> In article <2qkctv$[e-mail]> [e-mail]
([e-mail]) writes:
> >If you're learning C++ from Learn C++ on the Macintosh, you're going

> >to have serious problems using C++ for any medium to large-sized
> >project.  I agree with Susan on "Learn C.."- I know of no one who has

> >actually learned good C programming from it.  There are *good* C (and

> >C++) books out there.  They usually assume you have a PC or Unix, but

> >so does "Learn C on the Macintosh" (printf and fopen are not
Macintosh
> >calls, you see).  Get one of them instead.
>
>     How about a nice list, Because I would like to get some books on Mac

> c/C++ programing.
>
> Stephan Fassmann   InterNet: $[e-mail]   GEnie:
S.FASSMANN
> carpe diem                                                carpe
noctem

"Practical C Programming" from O'Reilly & Associates is one of the best
C books out there.  It assumes UNIX -- it is an O'Reilly book, after
all. :-)

TTFN,
Chris

+++++++++++++++++++++++++++

>From [e-mail] (Ken Long)
Date: Thu, 12 May 1994 01:11:39 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

I wouldn't recommend Dave Mark's "Learn C on the Mac" as a first Mac C
book.  Dan Parks Sydow ([e-mail]) has put out two great beginner
and beginner/intermediate Mac C books.  They illustrate what they
discuss.  Get "Think THINK C!" first.  This will get you well into the
idea, concept and viewpoint of programming on a MAC (leave the DOS C
books alone for a while).  Once you get that, and get through it, get
Think C 5.0.4, since it's simplest and most available example source runs
on it without complication.  Also get at least old volume I and II of
Inside Mac (if you're low on funds.  If not, get all current IM volumes
available.

Read the IM on what you have already learned, so you can see what the
explanations connect with, anh how.  That way, when you read on something
you haven't learned, you'll be better able to make a connection.

Once you've gotten into it you can kind of tell which way to go from
there.  I'd recommend Dan's second book - Macintosh Programming
Techniques - to drive in the foundation of what you'll need to go on.
Then get the Primer books and their disks (saves typing all that in - or
scan and OCR it).

Many other books are just example sourc and explanations with some new
(to the beginner) how-to.  If you want details on specifics, like ANSI C
stuff, get The C Programming Language (the "K&R" book).  The Think C 5.x
Standard Libraries manual is excellent, too.

But a major source of "how to program" is example source.  Download as
much as possible.  Example code that runs is a competent programmer
telling you HOW to do some aspect of programming.  "Competent" simply
means he or she wrote a program that runs.  It may not be optimumly
coded, but it does run.

"How do I write a Main Event Loop?"  I look at as many Main Event Loops
in as many example source projects as it takes to get the idea of how
they are done.  This shows differences, similarities and identities
among them, and I can spot how and where to put modifications in.

So, those two books, TC 5 (you can update later), New Inside Mac andas
much example C source as you can get.  Straight Think C source is the
vast majority of example source you'll find.  Not Pascal, not C++.  Go
with the flow.

-Ken-

---------------------------

>From [e-mail] (Brandon Allen)
Subject: Basic, basic windows & PICT drawing
Date: 13 May 1994 14:13:59 -0600
Organization: University Of Utah Computer Center


Somebody posted, asking for simple code regarding windows and displaying
PICT's.  I can't find the thread now, but here is a bit of code that may
prove instructive.  I hope it's not TOO basic for you.  I'd be happy to
answer any other questions (for which I have answers).  Just e-mail me, if
you like.  I don't know it all, but I'll be glad to tell you what I do know.

___________________________________________________________________________
{ Ok, I'm assuming that you know how to create }
{WIND & PICT resources using ResEdit . }
{ The first thing you'll need to do is load the}
{ WIND data using the GetNewCWind call, }
{ this function will return a WindowPtr to }
{ the window you are creating.}

PROGRAM ShowAWindow;

 VAR
  myWindow: WindowPtr;
{ A pointer to your window data }
  windowID: Integer;
{ ID number of your WIND resource }
  pictureID: Integer;
{ ID of your Pict resource }
  myPicture: PicHandle;
{ Handle to the PICT }
  myRect: Rect;
{ A rectangle that will enclose the PICT }
{ when it is drawn }

BEGIN
 windowID := 666;
{ Or whatever number you choose as }
{ your resource ID }

 myWindow := GetNewCWindow(windowID, NIL, WindowPtr(-1));

{ Now, the nil after the windowID tells }
{ the Mac to allocate some new memory for }
{ your window, rather than using some }
{ that you have already allocated for it. }
{ The WindowPtr(-1) tells the computer }
{ which window to display the new }
{ window BEHIND.  For instance if you }
{ wanted your new window to appear behind }
{ a window whose data was contained in a }
{ variable called frontWind, then you }
{ would use frontWind instead.  In this case }
{ we want this window to be the }
{ front-most window, so we send a }
{ WindowPtr that points to the value -1. }
{ This is a standard value that tells the }
{ computer not to display your window }
{ behind any other window. }

 SetPort(myWindow);

{ Now that we have created and displayed }
{ our window where we want it, we }
{ designate it as the current graphics port. }
{ This means that any drawing you }
{ do in your program will occur in this window. }

 myPicture := GetPicture(pictureID);

{ This call loads your PICT resource into memory }

 IF myPicture <> NIL THEN
  BEGIN
   myRect := myPicture^^.picFrame;
   DrawPicture(myPicture, myRect)
  END;

{ This bit of code ensures that the previous call }
{ to GetPicture was successful.  If the PICT had }
{ not been loaded, myPicture would contain NIL. }
{ If it doesn't contain NIL, we'll go ahead and draw }
{ it into our window with the DrawPicture call. }
{ Obviously myPicture is the handle we just }
{ created with the GetPicture call.  myRect is }
{ the rectangle into which the picture will be }
{ drawn.  This Rect is in local coordinates for }
{ your window (0,0 corresponds to the upper }
{ left hand corner of your window, not of }
{ the screen).  If myRect is different from the }
{ size of your PICT, QuickDraw will resize it }
{ automatically.  Thus, the assignment of the }
{ PICT's Rect (myPicture^^.picFrame) to }
{ myRect keeps the PICT at its original size. }


{ The rest of your program here ... }

END.

---------------------------

>From [e-mail] (Jon Blossom)
Subject: Help: Palette translation in CopyBits
Date: Tue, 3 May 1994 01:14:07 GMT
Organization: Microsoft Corporation

I'm trying to create an off-screen GWorld whose palette
matches the palette of the window I'm copying to.

What happens is that I set up a palette, say entry 3
is red, and set it up for both the GWorld and the window.
Then I poke a 3 somewhere into the GWorld memory, but
when I call CopyBits(), the color's been translated to something
else.

If I do a PmForeColor(3) then poke the result of a GetForeColor(),
I get the correct results.

Somewhere, QuickDraw is remapping colors.

Anyone know how to prevent QuickDraw from remapping so that I
have an identity relationship between the color table in my
off-screen GWorld and the palette in my window? I don't
want to have to go through this cheesy translation step!

Thanks

-Jon Blossom
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Graham Cox)
Date: Fri, 6 May 1994 16:33:02 GMT
Organization: School of Information Systems, UEA, Norwich

In article <[e-mail]>, [e-mail] (Jon Blossom)
wrote:

> I'm trying to create an off-screen GWorld whose palette
> matches the palette of the window I'm copying to.
>
> What happens is that I set up a palette, say entry 3
> is red, and set it up for both the GWorld and the window.
> Then I poke a 3 somewhere into the GWorld memory, but
> when I call CopyBits(), the color's been translated to something
> else.
>
> If I do a PmForeColor(3) then poke the result of a GetForeColor(),
> I get the correct results.
>
> Somewhere, QuickDraw is remapping colors.
>
> Anyone know how to prevent QuickDraw from remapping so that I
> have an identity relationship between the color table in my
> off-screen GWorld and the palette in my window? I don't
> want to have to go through this cheesy translation step!
>
> Thanks
>
> -Jon Blossom
> [e-mail]


Gosh, someone at Microsoft asking how to do things properly! Whatever next!

I suppose I should be nice and try and help, though actually I don't know
the exact answer. However, it is definitely documented in Inside Mac VI in
the Palette Manager chapter. You have to set up your GWorld colour table to
the be the same as the window's colour table, then build a palette for the
window which uses Animated Colours. Then you can draw using indexed values.

However, do you NEED to do this? (examine the problem carefully). Normally
you should be working with RGB Colours, and drawing using QuickDraw into
the GWorld- life will be easy if you do it this way, and don't try to draw
with indexes. Of course, there are times when you might legitimately want
to do this, but as I don't know what the problem is in this case, then it's
hard to be sure.

One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image
directly- this is a sure fire way of making a program incompatible with the
video device. If QuickDraw doesn't know about the contents of an image
(because you bypassed it) you will almost certainly not end up with what
you want.

Please do it right- I know we all love to hate MS products on the Mac, but
they COULD be really good if more people like you asked questions!!!

- ------------------------------------------------------------------------
Graham

-Everyone is entitled to their opinion, no matter how wrong they may be...
- ------------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail]
Date: 7 May 94 10:59:55 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Graham Cox) writes:
> In article <[e-mail]>, [e-mail] (Jon Blossom)
> wrote:
>
>> I'm trying to create an off-screen GWorld whose palette
>> matches the palette of the window I'm copying to.
>>
>> What happens is that I set up a palette, say entry 3
>> is red, and set it up for both the GWorld and the window.
>> Then I poke a 3 somewhere into the GWorld memory, but
>> when I call CopyBits(), the color's been translated to something
>> else.
>>
>> If I do a PmForeColor(3) then poke the result of a GetForeColor(),
>> I get the correct results.
>>
>> Somewhere, QuickDraw is remapping colors.
>>
>> Anyone know how to prevent QuickDraw from remapping so that I
>> have an identity relationship between the color table in my
>> off-screen GWorld and the palette in my window? I don't
>> want to have to go through this cheesy translation step!
>>
>
[snip]

> One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image
> directly- this is a sure fire way of making a program incompatible with the
> video device. If QuickDraw doesn't know about the contents of an image
> (because you bypassed it) you will almost certainly not end up with what
> you want.

What if you are trying to get a video-game to go as fast as possible?
OBviously, QuickDraw is too slow for such purposes...

>
> --------------------------------------------------------------------------
> Graham
>
> -Everyone is entitled to their opinion, no matter how wrong they may be...
> --------------------------------------------------------------------------

Lawson

+++++++++++++++++++++++++++

>From [e-mail] (John Stiles)
Date: 7 May 1994 22:19:15 GMT
Organization: California State University, Bakersfield

>>> Anyone know how to prevent QuickDraw from remapping so that I
>>> have an identity relationship between the color table in my
>>> off-screen GWorld and the palette in my window? I don't
>>> want to have to go through this cheesy translation step!
>>>
    The same thing happened to me. The GWorld was assigned a clut, this
clut was changed to a palette and was applied to a window. Still, CopyBits
wanted to do colormapping. Great.
    I did notice that the mapping was 0 to 0, 1 to 1, 2 to 2, ... 255 to
255--i.e., no change. (it had to be with the custom palette I was using!)
    The only workable solution was to implement a cheap blitter. It worked
and I got it running faster than CopyBits anyway. So, problem solved. Still,
there should be a more acceptable solution.
                                *Stiles


+++++++++++++++++++++++++++

>From [e-mail] (Joseph Hall)
Date: Sun, 8 May 1994 23:40:17 GMT
Organization: Motorola Inc., Satellite Communications

Seems it was [e-mail] who said:
>What if you are trying to get a video-game to go as fast as possible?
>OBviously, QuickDraw is too slow for such purposes...

Obviously, you have never used a properly-aligned CopyBits.

There is no need to draw directly into screen memory on the Mac.  Munge
your bits in your favorite quickest, hairiest way offscreen and then use
QuickDraw to copy them onto the screen.

I'll grant that QuickDraw's line- and circle-drawing algorithms are
both slow and a little weird, but you don't have to use *them* to draw
into an offscreen area.

--
Joseph Nathan Hall | Joseph's Law of Interface Design: Never give your users
Software Architect | a choice between the easy way and the right way.
Gorca Systems Inc. |                 [e-mail] (home)
(on assignment)    | [phone] (work)  [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Francois Pottier)
Date: 9 May 1994 10:11:30 GMT
Organization: Ecole Normale Superieure, PARIS, France

In article <2qh453$[e-mail]>,
John Stiles <[e-mail]> wrote:

>    The same thing happened to me. The GWorld was assigned a clut, this
>clut was changed to a palette and was applied to a window. Still, CopyBits
>wanted to do colormapping. Great.
>    I did notice that the mapping was 0 to 0, 1 to 1, 2 to 2, ... 255 to
>255--i.e., no change. (it had to be with the custom palette I was using!)
>    The only workable solution was to implement a cheap blitter. It worked
>and I got it running faster than CopyBits anyway. So, problem solved. Still,
>there should be a more acceptable solution.

There is one. Just replace the destination color table's ctSeed with
the source table's one. This will let CopyBits know that the color tables
are indeed equal, and no mapping will be performed. I think it is described
in Inside Mac, but I don't know for sure, since Imaging hasn't appeared in
French bookstores yet.


--
Francois Pottier                                            [e-mail]
- ----------------------------------------------------------------------------
This area dedicated to the preservation of endangered species.         "Moof!"

+++++++++++++++++++++++++++

>From Phil Smy <[e-mail]>
Date: 10 May 1994 18:42:26 GMT
Organization: Innotech MultiMedia Corp.

In article <2ql28i$[e-mail]> Francois Pottier,
[e-mail] writes:
>There is one. Just replace the destination color table's ctSeed with
>the source table's one. This will let CopyBits know that the color tables
>are indeed equal, and no mapping will be performed. I think it is
described
>in Inside Mac, but I don't know for sure, since Imaging hasn't appeared
in
>French bookstores yet.

Here's what I do to make a GWorld with matching palette:

        thePal = GetPalette(front->macPort);
        if (thePal)
        {
            offColors = GetCTable(ktheCLUT);
            Palette2CTab(thePal,offColors);
        }

        GetGWorld(&savePort,&saveDevice);

        depth = (*(*saveDevice)->gdPMap)->pixelSize;
        depth = depth & 0x0000FFFF;

        error = NewGWorld(&offPort, depth ,&borderRect,offColors,nil,0);
        if (error != noErr)
            // do something about this!

        SetGWorld(offPort,nil);

I have had no colour mapping problems doing this. I don't know if this
helps.

Phil
******************************************************************
* Phil Smy                    * Interactive CDRom MultiMedia     *
* Sr. Developer               * #include <stddisclaimer.h>       *
* Innotech MultiMedia Corp.   * Wot Gorilla?                     *
******************************************************************

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: 10 May 1994 19:56:42 -0700
Organization: Skunkworks

In article <2qh453$[e-mail]>,
John Stiles <[e-mail]> wrote:
>>>> Anyone know how to prevent QuickDraw from remapping so that I
>>>> have an identity relationship between the color table in my
>>>> off-screen GWorld and the palette in my window?
>       The same thing happened to me. The GWorld was assigned a clut, this
>clut was changed to a palette and was applied to a window. Still, CopyBits
>wanted to do colormapping.

Did you try setting bit 14 of ctFlags?  Take a look at the
palette manager article in issue 5 of develop and the ctSeed
reference in the Palette Manager chapter of Inside Mac VI
for a discussion of how to use that bit to avoid unintended
color mappings.

Grobbins            [e-mail]

Usual disclaimers apply.


+++++++++++++++++++++++++++

>From [e-mail]
Date: 10 May 94 21:51:32 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Joseph Hall) writes:
> Seems it was [e-mail] who said:
>>What if you are trying to get a video-game to go as fast as possible?
>>OBviously, QuickDraw is too slow for such purposes...
>
> Obviously, you have never used a properly-aligned CopyBits.
>
> There is no need to draw directly into screen memory on the Mac.  Munge
> your bits in your favorite quickest, hairiest way offscreen and then use
> QuickDraw to copy them onto the screen.
>
> I'll grant that QuickDraw's line- and circle-drawing algorithms are
> both slow and a little weird, but you don't have to use *them* to draw
> into an offscreen area.
>

I'm sorry. From what you had said (as I dimly recall it), you seemed to be
advocating the use of QuickDraw for *everything*.

Obviously, CopyBits is part of QUickDraw, but I was taking you to mean circles
and so on as well...

Lawson (formerly 103T_English... The Sys Admin got her lines crossed and renamed
my account with my brother's... imagine my surprise...)

+++++++++++++++++++++++++++

>From Mark Hanrek <[e-mail]>
Date: Wed, 11 May 1994 12:06:41 GMT
Organization: The Information Workshop

In article <[e-mail]> Graham Cox,
[e-mail] writes:

>> I'm trying to create an off-screen GWorld whose palette
>> matches the palette of the window I'm copying to.

In addition to the suggestions regarding the ctSeed, try taking the
following approach.

- -- Color Tables


If you can, try to avoid thinking of "a palette of colors" because
this English expression ends up confusing us when working with the
Palette Manager, which is clearly from another planet. :)

Try an approach that has worked well for me, of working with
color tables at all times, until the very last minute.

Then, when you are ready to activate the colors you need, just before
drawing to the window, create a palette from your color table using
CTab2Palette.  E-Z.

If you are going to be drawing into a GWorld, have the color table with
the colors you want already attached to the GWorld. It helps to
have the color table supplied when you create the GWorld as well.

For example, say you want to read in and draw a GIF picture....

  - Read in the GIF data, and extract the color table and picture rect.
  - Create a color table with the picture's colors in it.
  - Create a GWorld of the proper rect and supply the color table, too.
  - While decoding the GIF's pixels, write the values directly into the
      GWorld's pixels, after having locked it down, natch.
  - Create a palette from the color table using CTab2Palette.
  - Activate the colors using NSetPalette and ActivatePalette
  - Copybits from the GWorld to the window.

Also, observe the unwritten rules of always doing...

        ForeColor( blackColor );
        BackColor( whiteColor );

before performing a CopyBits.

- --- Palettes

Also, it is good to be up on what the Palette Manager is doing.

There is an informative article in the March '93  d e v e l o p  called
"The Palette Manager Way" in the Graphical Truffles column.

It describes how one can use the pmTolerant + pmExplicit usage modes
to ensure that the positions of your colors don't change when your
palette is activated.

Keep in mind that when you activate your palette, the Palette Manager
is arbitrating your "request" with the needs of the rest of the windows.

If you must have the exact colors you specify, then always use the
pmTolerant + pmExplicit mode when you are creating your color tables
and palettes.

One thing that helped me get the hang of things was always creating
palettes and color tables using  ( pmTolerant + pmExplicit ) in the
appropriate parameter.

Things will work as you expect because you are essentially "insisting"
that the Palette Manager give you exactly what you are asking for, and
leave things in the positions you have them in.

Once you get things working, then as a separate exercise you can
relax your color needs and experiment with the usage modes, if by
some freak accident of nature you actually have some extra time.  :)

Hope this helps.

Mark Hanrek

+++++++++++++++++++++++++++

>From [e-mail] (Jon Blossom)
Date: Thu, 12 May 1994 02:59:06 GMT
Organization: Microsoft Corporation

>> One thing I do know is- NEVER,NEVER,NEVER poke indexes into the pixel image
>> directly- this is a sure fire way of making a program incompatible with the
>> video device. If QuickDraw doesn't know about the contents of an image
>> (because you bypassed it) you will almost certainly not end up with what
>> you want.
>
>What if you are trying to get a video-game to go as fast as possible?
>OBviously, QuickDraw is too slow for such purposes...

Which is basically exactly what I'm trying to do.

For certain applications, QuickDraw just isn't fast enough. For instance, my
polygon fills beat QD by about 25% or more because I know exactly how I want
to draw them.

What I really want to do is build my image the way I want it then say
"QuickDraw, here is a picture. Put it on the screen as fast as you can."

Unfortunately, I know that it's NOT going as fast as it can because it's doing
this damn color translation along the way even though I know it doesn't have
to.

-Jon Blossom
[e-mail]



---------------------------

>From [e-mail] (Moshe Segal)
Subject: How do I draw masked icons w-System 6?
Date: Tue, 10 May 1994 15:33:15 GMT
Organization: Wright State University, Dayton, OH 45435

Does anybody know how to accomplish the following task: Display an ICN#
resource in a window using System 6. You may recall that almost all of
the icon utilities are only available on System 7, while the commands like
"GetIcon" only display ICON resources, which have no mask and leave an
unsightly white square around them when displayed.

I know it must be possible to display ICN# resources on pre-System 7
platforms. Indeed, a game called "Icon Bounce" does this beautifully. At
first I thought that was done by storing the ICN# patterns and masks as
regions.  But, alas, I couldn't figure out to get a pointer or handle to
the bitmap fields of the icon.

Anyone know the answer or know where I could find it on the net or in a
book (I have only the new Inside MacIntoshes). Or, does anyone have the
source code for the aforementioned Icon Bounce game?  Please post the
response, as I am on a friends account.

Michael E. Kotler




+++++++++++++++++++++++++++

>From Matt Slot <[e-mail]>
Date: 10 May 1994 21:01:38 GMT
Organization: University of Michigan

Moshe Segal, [e-mail] writes:

>Does anybody know how to accomplish the following task: Display an ICN#
>resource in a window using System 6. You may recall that almost all of
>the icon utilities are only available on System 7, while the commands like
>"GetIcon" only display ICON resources, which have no mask and leave an
>unsightly white square around them when displayed.

Here is a snippet I extracted from some Icon plotting tools that I wrote.
I found the technique in a TechNote (I think). It works for both System 6
and System 7.

This code is was snipped from a program I wrote and wrapped into a little
function... it should be ready for dropping into a program with no bugs.

Matt Slot
[e-mail]

void PlotIconInAllSystems(short iconID, Boolean hilited, Rect *iconRect) {
    BitMap iconMap;
    Handle iconHdl;

    if (!hasSys7 || PlotIconID(&iconRect, 0, (hilited) ? ttSelected : 0, iconID)) {
        if (iconHdl = GetResource('ICN#', iconID)) {
            HLock(iconHdl);

            iconMap.baseAddr = *iconHdl;
            iconMap.rowBytes = 4;
            SetRect(&iconMap.bounds,0,0,32,32);
            CopyBits(&iconMap, &thePort->portBits,
                    &iconMap.bounds, &iconRect, srcCopy, 0);

            if (hilited) {
                iconMap.baseAddr += 128;
                CopyBits(&iconMap, &thePort->portBits,
                        &iconMap.bounds, &iconRect, srcXor, 0);
                }

            HUnlock(iconHdl);
            ReleaseResource(iconHdl);
            }
          else FrameRect(&iconRect);    // Something went wrong -- wimp out
        }
    }

+++++++++++++++++++++++++++

>From Richard Knuckey <[e-mail]>
Date: Fri, 13 May 94 20:15:37 +1200
Organization: Purple X's Humble Macintosh


The following mimics all of the system 7 icon drawing styes (in black and
white only) It is cut from a larger and more complete icon handling unit.

const
  largeRowBytes = 4;
  smallRowBytes = 2;
  miniRowBytes = 2;

  largeMaskOffset = largeIconSize * largeRowBytes;
  smallMaskOffset = smallIconSize * smallRowBytes;
  miniMaskOffset = miniIconSize * miniRowBytes;

type
  IconListHandle = ^IconListPtr;
  IconListPtr = ^IconListType;
  IconListType = record
    icon: packed array[1..32] of longint;
    mask: packed array[1..32] of longint;
  end;


procedure DrawIconList (iconBounds: Rect; iconSize, transform: integer;
                        iconData: univ Handle);
var
  iconBitMap, maskBitMap: BitMap;
  iconDisabled, iconOffLine, iconOpen, iconSelected: Boolean;
  copyMode, iconTransform: integer;
  drawPort: GrafPtr;

begin
  GetPort(drawPort);
  HLock(iconData);

  with iconBitMap do
    begin
      baseAddr := iconData^;
      bounds := iconBounds;
      maskBitMap := iconBitMap;

      case iconSize of
        largeIconSize:
          begin
            rowBytes := largeRowBytes;
            maskBitMap.rowBytes := largeRowBytes;
            maskBitMap.baseAddr := Ptr(ord4(baseAddr) + largeMaskOffset);
          end;

        smallIconSize:
          begin
            rowBytes := smallRowBytes;
            maskBitMap.rowBytes := smallRowBytes;
            maskBitMap.baseAddr := Ptr(ord4(baseAddr) + smallMaskOffset);
          end;

        miniIconSize:
          begin
            rowBytes := miniRowBytes;
            maskBitMap.rowBytes := miniRowBytes;
            maskBitMap.baseAddr := Ptr(ord4(baseAddr) + miniMaskOffset);
          end;

        otherwise
          begin
            HUnlock(iconData);
            exit(DrawIconList);
          end;
      end;
    end;

  {the transform type is in the lower nibble}
  iconTransform := BAND(transform, $000F);
  iconDisabled := iconTransform = ttDisabled;
  iconOffline := iconTransform = ttOffline;
  iconOpen := iconTransform = ttOpen;
  iconSelected := BAND(transform, ttSelected) <> 0;

  if iconOffline | iconOpen then
    begin
      PenMode(patXor);
      if iconSelected then
        PenPat(dkGray)
      else
        PenPat(ltGray);
      PaintRect(iconBounds);
    end;

  if (not (iconOffline | iconOpen)) & iconSelected then
    copyMode := srcOr
  else
    copyMode := srcBic;
  CopyBits(maskBitmap, drawPort^.portBits, iconBounds, iconBounds,
           copyMode, nil);

  if iconDisabled then
    begin
      PenMode(patXor);
      PenPat(gray);
    end;

  if iconOpen | iconOffline | iconDisabled then
    PaintRect(iconBounds);

  if (not iconOpen) then
    begin
      if iconOffline then
        if iconSelected then
          copyMode := srcBic
        else
          copyMode := srcOr
      else if iconDisabled then
        copyMode := srcBic
      else
        copyMode := srcXor;

      CopyBits(iconBitmap, drawPort^.portBits, iconBounds, iconBounds,
               copyMode, nil)
    end;

  if iconDisabled then
    PaintRect(iconBounds);

  PenMode(patOr);
  PenPat(black);

  HUnlock(iconData);
end;


---------------------------

>From [e-mail] (Julie Shipnes)
Subject: Motorola announces Power Mac compilers
Date: 12 May 1994 16:29:40 -0500
Organization: Motorola RISC Software, Austin, TX


 MOTOROLA ANNOUNCES HIGH-PERFORMANCE POWERPC MICROPROCESSOR
             COMPILERS FOR POWER MACINTOSH

  AUSTIN, Texas, May 10  -- Motorola's RISC Microprocessor Division
today announced plans to port its optimizing PowerPC microprocessor compilers
to Apple's complete line of Power Macintosh computers.  The C, C++ and FORTRAN
compilers will be fully compatible with Apple's Macintosh Programmers'
Workshop (MPW) development environment and will enable developers
to simultaneously optimize code for each member of the PowerPC family
of microprocessors, including PowerPC 601(TM), PowerPC 603(TM),
PowerPC 604(TM) and PowerPC 620(TM).

  "The ability to take full advantage of the PowerPC performance features of
each member of the PowerPC family is a critical aspect of Motorola's
commitment to provide a complete solution for our customers," said Les
Crudele, vice president and general manager, Motorola RISC Microprocessor
Division.  "Our compilers will permit developers to leverage the performance
potential of current and future PowerPC microprocessors without the need to
recompile applications."

  The compilers, which are currently being tested within Apple and at select
beta sites, have demonstrated significant performance improvements for
critical applications.  Much of the performance increase is because the
Motorola compilers optimize code to take advantage of individual features of
the superscalar PowerPC microprocessors, while still maintaining code
compatibility across all PowerPC architecture family members.

  The compilers can be configured to optimize code for a particular chip
implementation, or they can generate a series of objects that target
multiple PowerPC microprocessor.  As a result, developers can develop
applications now that will be optimally configured for existing and future
Apple systems.

  "By integrating their compiler development with the PowerPC chip design
efforts in Austin, Motorola is in a unique position to bring highly
optimizing compilers to market quickly for forthcoming PowerPC
microprocessors," said Peter Christy, senior director of developer products
engineering at Apple Computer, Inc. "The Motorola compilers complement the MPW
compilers and tools already available from Apple and others, and provide
Macintosh developers with a more complete set of options for creating
high-performance applications for the exciting Power Macintosh platform."

  Motorola has also announced its intention to integrate its compilers into
the CodeWarrior development environment offered by Metrowerks, Inc. By
supporting both the MPW and CodeWarrior environments, users will be able to
leverage the performance advantages of the Motorola compilers without
needing to adopt a new development environment.

  "The addition of Motorola's compilers to the CodeWarrior environment will
offer an immediate performance boost for those CodeWarrier developers that
are working on leading-edge applications for future implementations of
PowerPC microprocessors," said Metrowerks president and CEO Greg Galanos.
According to Galanos, Metrowerks is defining a tools and language interface
for CodeWarrior that will permit developers to use standardized language
conventions and user interfaces for a variety of development tools.

  Motorola will accept orders in July 1994 for the MPW-based compilers and
tools running native on Power Macintosh and 68000-based Macintosh systems at
an initial list price of $349.  The company will offer a beta version of the
compiler for CodeWarrior in late 1994.  For additional information,
customers can call 800-845-MOTO.

  PowerPC microprocessors are based on reduced instruction set computing
(RISC) and incorporate leading edge technologies from IBM and Motorola.  The
family of PowerPC microprocessors is designed to address a wide range of
computing requirements, from portable and desktop computers to midrange
workstations and servers, to multi-processing, fault-tolerant and
supercomputing systems.  PowerPC microcontrollers also will be used for
embedded control applications in automotive and consumer products.

  Companies developing PowerPC systems and subsystems include Apple
Computer, Canon, DayStar Digital, Ford Motor Co., Groupe Bull, Harris,
Hitachi, IBM, ISG Technologies, Mercury Computer Systems, Motorola Computer
Group, Parsytec, PowerHouse, Scientific Atlanta, Shannon Computer, Tadpole
Technologies, the Taiwan New PC Consortium, THOMSON-CSF and YARC.

  Having 1993 worldwide sales of $5.7 billion, Motorola's Semiconductor
Products Sector is the largest U.S.-based broad line supplier of
semiconductors, with a balanced portfolio of more than 50,000 devices.
Motorola is one of the world's leading providers of wireless communications,
semiconductors, and advanced electronic systems and services.  Major
equipment businesses include cellular telephone, two-way radio, paging and
data communications, personal communications, automotive, defense and space
electronics and computers.  Communications devices, computers and millions
of consumer products are powered by Motorola semiconductors.  Motorola's
1993 sales were $17 billion.

  NOTE: Product names are trademarks of their respective companies. PowerPC,
PowerPC architecture, PowerPC 601, PowerPC 603, PowerPC 604 and PowerPC 620
are trademarks of International Business Machines Corporation and are used
by Motorola under license from International Business Machines Corporation.

CONTACT: (reader/Inquiry response) Motorola, Inc. RISC Microprocessor
Division, P.O.  Box 202558, Austin, Texas, 78720-9895, 1-800-845-MOTO



- -------------------------- Oakhill -------------------------------
Julie Shipnes                        Mike Phillip
[e-mail]               [e-mail]

Motorola RISC Compiler Development
- -------------------------------------------------------------------

---------------------------

>From [e-mail] (Simon Jensen_Fellows)
Subject: Polling the Serial Port
Date: 28 Apr 1994 21:27:18 GMT
Organization: [MindVox] / Phantom Access Technologies / (+1 800-MindVox)

Hi,
Anyone got any advice about running a background process that polls the
serial port ?
I have tried posting a VBL routine, patching a trap and just running a
background application.

My main problem is that I seem to loose all my settings (Baud rate,
parity etc) once I exit the routine back to the O/S.

I guess I`m doing something wrong: any advice or sample code ?

Thanking you in advance.

Simon.


+++++++++++++++++++++++++++

>From [e-mail] (Evan Olcott)
Date: 29 Apr 1994 22:50:13 GMT
Organization: Centor Freed Inc.

Best thing to do is to patch WaitNextEvent. Open the serial drivers
upon startup (a lovely piece of extension code) and hold them in an A4
global buffer. Upon each call to your patch, get the globals (to get
the refNum and other stuff) and check the port.
Seems to work for me. Now the tricky part is serial port arbitration...
;-)

Evan Olcott, programmer
Centor Freed Inc.
100 N. 6th Street #989C
Minneapolis, MN 55417
"There are no experimental failures. There's only more data." - Bryce

+++++++++++++++++++++++++++

>From [e-mail] (David Phillip Oster)
Date: Thu, 12 May 1994 19:59:24 GMT
Organization: Netcom Online Communications Services (408-241-9760 login: guest)


You'd have to be absolutely insane to poll the serial ports. Anybody in their
right mind would do a PBRead(&io, TRUE); i.e., an asynchronous read. The
operating system will call your completion routine at interrupt level when
the read completes: you never need to poll. Your completion routine can do
another read.  You may want to set up a deadman-switch VBL task: your
completion routine is expecting data in at most 10 seconds, so it sets up
a VBL task with a 15 second timeout. If the read completes, the completion
routine cancels the VBL and starts a fresh one. If something went wrong,
the VBL gives you back control so you can fix things (like re-enable the
serial ports, notify the user that something went wrong, etc.)

Back in '85 I used this technique to interface serial digitizing tablets

---------------------------

End of C.S.M.P. Digest
**********************